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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Speech and multimedia 
Transmission Quality (STQ). 

The present document is part 5 of a multi-part deliverable covering the QoS aspects for popular services in GSM and 
3G networks, as identified below: 

Part 1 : "Identification of Quality of Service criteria" ; 

Part 2: "Definition of Quality of Service parameters and their computation"; 

Part 3: "Typical procedures for Quality of Service measurement equipment"; 

Part 4: "Requirements for Quality of Service measurement equipment"; 

Part 5: "Definition of typical measurement profiles"; 

Part 6: "Post processing and statistical methods". 

Part 1 identifies QoS aspects for popular services in GSM and 3G networks. For each service chosen QoS indicators are 
listed. They are considered to be suitable for the quantitatively characterization of the dominant technical QoS aspects 
as experienced from the end-customer perspective. 

Part 2 defines QoS parameters and their computation for popular services in GSM and 3G networks. The technical QoS 
indicators, listed in part 1, are the basis for the parameter set chosen. The parameter definition is split into two parts: the 
abstract definition and the generic description of the measurement method with the respective trigger points. Only 
measurement methods not dependent on any infrastructure provided are described in the present document. The 
harmonized definitions given in the present document are considered as the prerequisites for comparison of QoS 
measurements and measurement results. 

Part 3 describes typical procedures used for QoS measurements over GSM, along with settings and parameters for such 
measurements. 

Part 4 defines the minimum requirements of QoS measurement equipment for GSM and 3G networks in the way that 
the values and trigger-points needed to compute the QoS parameter as defined in part 2 can be measured following the 
procedures defined in part 3. Test-equipment fulfilling the specified minimum requirements, will allow performing of 
the proposed measurements in a reliable and reproducible way. 

Part 5 specifies test profiles which are required to enable benchmarking of different GSM or 3G networks both within 
and outside national boundaries. It is necessary to have these profiles so that when a specific set of tests are carried out 
then customers are comparing "like for like" performance. 
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Part 6 describes procedures to be used for statistical calculations in the field of QoS measurement of GSM and 
3G networks using probing systems. 



Introduction 

All the defined quality of service parameters and their computations are based on field measurements. That indicates 
that the measurements were made from customers point of view (full End-to-End perspective, taking into account the 
needs of testing). 

It is assumed that the end customer can handle his mobile and the services he wants to use (operability is not evaluated 
at this time). For the purpose of measurement it is assumed: 

• that the service is available and not barred for any reason; 

• routing is defined correctly without errors; and 

• the target subscriber equipment is ready to answer the call. 

Further preconditions may apply when reasonable. 

The present document describes a set of use cases which are precisely defined to allow for comparability between 
different measurements, possibly performed by different parties. 
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Scope 



The present document specifies test profiles which are required to enable benchmarking of different digital 
wireless networks both within and outside national boundaries. It is necessary to have these profiles so that when a 
specific set of tests are carried out then customers are comparing "like for like" performance. 

NOTE: All timeouts given in the present document are examples from proven experience. These examples are 

intended to provide guidelines for reasonable choice of timeout values for access technologies other than 
those given in the present document, mixed scenarios and different characteristics of user equipment. 

It should be noted that most timeouts given in the present document do with respect to failure ratios as defined in [1] 
have a direct impact on measurement results. A timeout value might for example directly relate to the stop trigger point 
in the sense of the timeout reached event being the point in time where a certain state has not been reached. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 250-2: "Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects 

for popular services in GSM and 3G networks; Part 2: Definition of Quality of Service parameters 
and their computation" . 

[2] ETSI TS 124 008: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Mobile radio interface Layer 3 specification; Core network 
protocols; Stage 3 (3GPP TS 24.008)". 

[3] IETF RFC 348 1 : "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks" . 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 
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3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 
Session: continuous usage of a given service, e.g. a speech call or a data session 
1 kByte: 1024 Byte 
1MByte: 1024 kByte 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AMR Adaptive Multi-Rate 

BCP Best Current Practice 

DNS Domain Name Server 

FQDN Fully Qualified Domain Name 

FTP File Transfer Protocol 

GPRS General Packet Radio Service 

GR GPRS Register 

HLR Home Location Register 

HTTP Hyper Text Transfer Protocol 

ICMP Internet Control Message Protocol 

IMAP Internet Messaging Access Protocol 

MMS Multimedia Messaging Service 

MO Mobile Originated 

MOC Mobile Originated Call 

MT Mobile Termination 

MTC Mobile Terminating Call 

PDP Pack Data Protocol 

PEP Performance Enhancement Proxy 

POP3 Post Office Protocol version 3 

PSD Packet Switched Data 

QoS Quality of Service 

SGSN Serving GPRS Support Node 

SMS Short Message Service 

SMTP Simple Mail Transfer Protocol 

TCP Transmission Control Protocol 

TCP/IP Transmission Control Protocol/Internet Protocol 

UDP User Datagram Protocol 

UMTS Universal Mobile Telecommunication System 

VT Video Telephony 

WAP Wireless Application Protocol 
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Measurement profiles 



Test profiles are required to enable benchmarking of different networks both within and outside national boundaries. It 
is necessary to have these profiles so that when a specific set of tests are carried out then customers are comparing "like 
for like" performance. 

It is recognized that many factors will affect comparability: 

number of sessions; 

sessions duration; 

time between sessions; 

demanded QoS settings for data services; 

protocol settings (like TCP/IP settings for data services or AMR-settings for speech services); 

usage profile during the session; 

fixed network test equipment like test servers for data sessions; 

user profile stored in the HLR or the GR; 

geographic location; 

type of location (indoor, hotspot, city, suburban, rural, train, etc.); 

speed when mobile; 

type of vehicle; 

type of antenna; 

handset type; 

handset hardware and firmware version; 

service being tested and limitations of service; 

network configuration; 

mobile users' population density. 

For the points mentioned above where there is no recommendation or requirement in the present document, the settings 
experienced by a normal customer of the service under test in the network under test shall be used as a guideline. 

As far as possible all particular values, e.g. timeout values, are named preserving the name of the respective Quality of 
Service parameters as defined in TS 102 250-2 [1]. 

4.1 Classification of measurement environments 

For interpretation and comparability of test results it is important to know in which measurement environment the tests 
were performed. The environment classifications described below shall be used. Since the type of the measurement 
locations may be interpreted differently, the particular understanding of the location type determining a category shall 
be described in the results report. 
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Table 1 : Stationary Tests 



Category 


Location Type 


Additional information 


S10: 


airports/railway stations/shopping centres and malls business districts and 
exhibition areas 


outdoor measurement 


S1I: 


airports/railway stations/shopping centres and malls business districts and 
exhibition areas 


indoor measurements 



Table 2: Drive Tests/Walk Tests 



Category 


Location Type 


Additional information 


D1: 


Train Measurements 




D2: 


Urban Areas (medium cities) 




D3: 


Highways 




D4: 


Rural Areas (country roads) 




D5: 


Large cities 




W1: 


Walk Tests (indoor measurements) 




W2: 


Walk Tests (outdoor measurements) 




NOTE: Drive tests may be performed by incar using external antenna with an appropriate attenuation. 



4.2 Service profiles 

This clause describes recommended service profiles used for testing. 

4.2.1 Telephony 

For all Telephony services it has to be stated, if the results were generated using MOC, MTC or a mix of both. The 
results for both types should be reported separately and should not be mixed. 

The default call duration used for telephony measurements should be 120 seconds. 

To achieve comparable statistics when performing a benchmark, there should be no fixed pause between calls. Instead, 
a fixed call window is defined in which the call has to be performed. If the call fails or drops, the next call attempt shall 
only be made when the next call window arrives. 

The minimum pause interval between two call attempts should be 30 seconds to prevent network related problems 
between connection release and the next establishment (e.g. signalling in the PSD or mobility management). 

4.2.1.1 Speech Telephony 

Speech Telephony should be tested either in MOC or in MTC direction. The following call durations shall be used: 

• CD1: 10 seconds for call setup testing; 

• CD2: 120 seconds for typical tests, default call duration; 

• CD3: 300 seconds for stability tests. 

Call Window: Call Duration + 30 seconds, (for the setup and release phases) + 30 seconds (for the minimum pause 
interval), for the default call duration this results in 180 seconds. 

Timeout values: 

• Telephony Service Non-Accessibility Timeout: 20 seconds; 

• Telephony Setup Time Timeout: 20 seconds. 

NOTE: Since the Telephony Setup Time corresponds, with respect to the trigger point definition, to the 

Telephony Service Non- Accessibility, both of timeout values above need to be chosen identically. 
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4.2.1 .2 Video Telephony 

Video Telephony should be tested either in MOC or in MTC direction. The following call durations shall be used: 

• CD1: 10 seconds for call setup testing; 

• CD2: 120 seconds for typical tests, default call duration; 

• CD3: 300 seconds for stability tests. 

Call Window: Call Duration + 30 seconds, (for the setup and release phases) + 30 seconds (for minimum pause 
interval), for the default call duration this results in 180 seconds. 

Timeout values: 

• VT Service Non- Accessibility Timeout: 20 seconds; 

• VT Service Access Time Timeout: 20 seconds; 

• VT Audio/Video Setup Time Timeout: 30 seconds. 

NOTE: Since the VT Service Access Time corresponds, with respect to the trigger point definition, to the VT 
Service Non- Accessibility, both of timeout values above need to be chosen identically. 



4.2.2 Messaging Services 



For all messaging services it is important that the recipient of a message is not interrupted by the next message while 
retrieving the previous one. For this reason it is important that the interval between sending two messages is larger than 
the 95 % percentile of the end-to-end duration, unless measures are taken to avoid this kind of interference. 

It should be noted, that mobility of either the sender or the receiver or both of a message can have an impact on the 
results. Therefore it is recommended that measurements are not only performed stationary, but also with mobility of one 
or both participants. In all cases the used scenario has to be stated. 

4.2.2.1 SMS 

SMS should be tested either in MO or in MT direction with respect to the mobiles used as measurement probes. The 
SMS should be 120 characters long and use different characters to test content integrity. The interval between two 
consecutive SMS shall be 70 seconds. 

The time window of measurements for calculating the Completion Rate SMS shall be 175 seconds. 

Timeout- values: 

• Service Accessibility SMS MO Timeout: 65 seconds; 

• Access Delay SMS MO Timeout: 65 seconds; 

• End-to-end Delivery Time SMS Timeout: 175 seconds. 

4.2.2.2 MMS 

MMS should be tested end to end. That means a MMS send by A-Party should be received by B -Party using also a 
mobile phone. The advantage of this testing is, that the MO direction at A-Party and the MT direction at B-Party can be 
measured. Both directions together are the end-to-end Parameters described in TS 102 250-2 [1]. 

The following MMS sizes shall be used: 

• MMS1: 2kBytes; 

• MMS2: 28 kBytes; 

• MMS3: 90 kBytes. 
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If the MMS is not delivered at the destination mobile after the MMS End-to-end Failure Ratio Timeout, the MMS 
delivery is considered failed. MMS delivered after this time is not taken into account for end-to-end delay, but into 
end-to-end failure ratio. 

Timeouts for MMS over GPRS: 

The timeouts for MMS Send, Retrieval and End-to-end Failure are dependent on the MMS size. For GPRS all MMS 
uploads with less than 5 kbits and all MMS downloads with less than 10 kbits are considered to be cut-off. 

MMS Send Failure Ratio (MO) Timeout and MMS Send Time (MO) Timeout: 

(195 + Size[kByte] x 8/5) [seconds]. 
MMS Retrieval Failure Ratio (MT) Timeout and MMS Retrieval Time (MT) Timeout: 

(195 + Size[kByte] x 8/10) [seconds]. 

The fixed part of 195 seconds incorporate the time for PDP context activation and WAP activation and shall be used as 
a whole, i.e. the single timeouts for PDP context and WAP activation shall not be considered. 

MMS end-to-end Delivery Failure Ratio Timeout and MMS End-to-end Delivery Time Timeout: 

(590 + Size[kByte] x 8/5 + Size[kByte] x 8/10) [seconds]. 

The fixed part of 590 seconds incorporate the time for PDP context activations, WAP activations and notification and a 
security margin. It shall be regarded as a whole, i.e. the single timeouts shall not be considered. 

MMS Notification Failure Ratio Timeout and MMS Notification Time Timeout: 120 seconds. 

Timeouts for MMS over UMTS: 

The timeouts for MMS Send, Retrieval and End-to-end Failure are dependent on the MMS size. 

The respective required minimum upload and download data rate is for further study. 

MMS send failure ratio (MO) Timeout and MMS Send Time (MO) Timeout: for further study. 

MMS Retrieval Failure Ratio (MT) Timeout and MMS Retrieval Time (MT) Timeout: for further study. 

MMS end-to-end Delivery Failure Ratio Timeout and MMS End-to-end Delivery Time Timeout: for further 
study. 

MMS Notification Failure Ratio Timeout and MMS Notification Time Timeout: 120 seconds. 

4.2.3 Data services 

4.2.3.1 Circuit switched 

Circuit switched data services shall be tested for 100 % MOC. Call duration shall be either 300 seconds or is defined by 
the usage profile used during the data session. The pause interval between call attempts shall be 30 seconds. The usage 
profile used during the data session is defined in clause 4.3. 

4.2.3.2 Packet switched 

Packet switched data services shall be tested for 100 % MOC sessions. Session duration shall be either 300 seconds or 
is defined by the usage profile used during the data session. The pause interval between session setup attempts shall be 
30 seconds. The usage profile used during the data session is defined in clause 4.3. 

NOTE: In order to ensure comparable results in benchmark testing (on changing access technologies) the number 
of measurements per time on the compared channels shouldbe equal (by using test windows or regular 
intermediate results) or the individual measurements should be appropriately weighted in the aggregation. 
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4.2.3.2.1 Service-independent timeout values 

• Attach Timeout: 75 seconds. 

It might occur that the mobile station sends more than one attach request towards the SGSN, since retries are necessary. 
A maximum of four retries are possible (timer T3310 expires after 15 seconds for each attempt, see TS 124 008 [2]. 

• PDP Context Activation Timeout : 150 seconds. 

It might occur that the mobile station sends more than one PDP context activation request towards the SGSN, since 
retries are necessary. A maximum of four retries are possible (timer T3380 expires after 30 seconds for each attempt, 
see TS 124 008 [2]). 

4.2.3.2.2 Service-dependent timeout values 
Timeout values for an FTP (ULandDL) service are: 

• Service Accessibility Timeout: 150 seconds + IP-Service Access Timeout; 

• Setup Time Timeout: 150 seconds + IP-Service Access Timeout; 

• IP-Service Access Timeout (and IP-Service Setup Time Timeout): 30 seconds; 

• Data Transfer Cut-off Timeout: 

Over GPRS: 

UL: File size[kByte] x 8/5; 

DL: File size[kByte] x 8/10. 

Over UMTS: 

ULandDL: File size[kByte] x 8/50. 
Dual mode: The average between the timeout over GPRS and UMTS shall be considered. 
Timeout values for an HTTP service are: 

• Service Accessibility Timeout: 150 seconds + IP-Service Access Timeout; 

• Setup Time Timeout: 150 seconds + IP-Service Access Timeout; 

• IP-Service Access Timeout (and IP-Service Setup Time Timeout): 30 seconds; 

• Data Transfer Cut-off Timeout: 

Over GPRS: 

UL: File size[kByte] x 8/5; 

DL: File size[kByte] x 8/10. 

Over UMTS: 

ULandDL: File size[kByte] X 8/50. 
Dual mode: The average between the timeout over GPRS and UMTS shall be considered. 
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Timeout values for an E-Mail (IMAP, POP3 and SMTP) service are: 

• Service Accessibility Timeout: 150 seconds + IP-Service Access Timeout; 

• Setup Time Timeout: 150 seconds + IP-Service Access Timeout; 

• IP-Service Access Timeout (and IP-Service Setup Time Timeout): 60 seconds; 

• Data Transfer Cut-off Timeout: 

Over GPRS: 

UL: File sizefkByte] X 8/5; 

DL: File size[kByte] x 8/10. 

Over UMTS: 

ULandDL: File size[kByte] X 8/50. 
Dual mode: The average between the timeout over GPRS and UMTS shall be considered. 
Timeout values for a streaming service are: 

• Streaming Service Access Timeout: 30 seconds; 

• Stream Reproduction Start Timeout (initial buffering): 60 seconds; 

• Rebuffering Timeout (Single): 30 seconds; 

• Rebuffering Timeout (Total): 75 % of session time; 

NOTE 1 : It might occur that a streaming client goes from rebuffering back to playback within the Rebuffering 

Timeout (Single), but goes back to one or more rebuffering periods afterwards. The Rebuffering Timeout 
(Total) defines a limit in terms of a maximum of allocated time for all rebuffering periods. 

• Max Allowed Rebuffering Frequency: 20 rebuf/min; 

NOTE 2: The streaming client might go into recurrent rebufferings. If the number of rebuffering occurrences within 
a minute exceeds this limit the session is aborted. 

• Teardown Timeout: 30 seconds. 

4.3 Usage Profiles for Data Sessions 

For data session measurements, the client application, e.g. web browser, FTP client or mail client, as well as the server 
application, e.g. web server, FTP server or mail server, should behave similar to the majority of client applications used 
by the customer and server application used by the data service providers. 

Also, the operating system on both sides, namely the client- and the server side, should be chosen with respect to the 
operating system commonly used by the customer and the data service provider, respectively. 

In case a network operating company whose network is to be measured provides the customer with some client 
application, it should be ensured that any change introduced by such application to the client operating system should 
have been applied prior to the measurement, as well. This is especially true for changes which would have an impacting 
on the measurement results, for example changes to the operating system's TCP stack. Such client applications are for 
example provided in order to allow the customer a single point of access to network related configurations and to data 
service clients, e.g. web browser, mail client, etc. Furthermore, such client application might optimize operating system 
parameters, including tuning of e.g. TCP settings, with respect to the connection type and technology to be used. 

NOTE 1 : In some cases it is desirable not to install such client application itself since this might have some 
unwanted impact on the measurement. For example, if such application would generate unwanted 
network traffic in order to check for updates or if the application would continuously try to connect to the 
mobile device preventing some measurement application form controlling the device. 
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NOTE 2: The use of different operating systems as well as the use of operating systems with different TCP 
parameter settings in general might have a large impact on the results obtained. With respect to the 
operating systems, this is due to the different implementations of the TCP/IP stack. This needs to be 
considered in case of benchmarking exercises where the client and/or server operating systems and/or the 
changes applied on the client sides of the compared networks are not the same. In any case, the settings of 
the TCP stack of both, the client and the server operating system should be recorded in order to allow for 
better interpretation and in-depth evaluation of the measurement data. 

NOTE 3: Proxy servers installed in the networks IP core network may act as the TCP peer instead of the application 
server the tests are performed against. In benchmarking scenarios, the existence of different Proxy servers 
might have an additional impact on the results, which should be considered when comparing them. 

NOTE 4: A reference for optimized TCP parameters over cellular networks, like second (2.5G) and third (3G) 

generation wireless networks, is the RFC 3481 [3] which is of the Best Current Practice (BCP) category 
in the IETF published in February of 2003. 

NOTE 5: Some of the client applications referred to above might also change the way a data service is accessed 
from the client side, for example by introducing some client to the customer's operating system which 
changes the transport protocol between the customers operating system and some proxy server. In such 
case, the trigger points as defined in TS 102 250-2 [1] might not be measurable anymore and should 
therefore be mapped to the application layer. Especially in case of benchmarking exercises where 
different operating systems are used on the client side, such mapping might have an additional influence 
on the measurements. The definition of such trigger point mappings for the different operations systems is 
not in the scope of the present document. 

For all tests a dedicated test server should be used as a well defined reference. Under no circumstances should a 
commercial server be used, since the content on such a server may change over time. This makes later reproduction of 
the results impossible. 

In order to avoid issues with DNS host name resolution like including effects of DNS caching strategies of the used 
operating system into the measurement,, the test server should either be identified by an IP address and not by its FQDN 
or it shall be ensured that the local Resolver will contact a remote DNS name server in case a host name resolution is 
requested by an application. Furthermore, the DNS name server should be able to perform the resolution within its local 
zone, in case DNS lookup time is to be included into any quality of service parameter to get calculated. The later is 
needed in order to exclude effects of DNS caching strategies of the DNS name server(s) involved into the measurement. 

The measurement of data services should take place against a reference server only used for testing purposes. The 
reference server should be connected to public the internet with a link capable of carrying the accumulated traffic of all 
mobiles testing against that server (e.g. if a benchmark with 4 networks is performed, the server should be able to 
deliver at least 4 times the maximum nominal speed of a single wireless link). There should be no bias concerning the 
IP connectivity to this server from a specific operator (e.g. bandwidth or hop-count). 

The capabilities of the test UE shall be stated in the results report. 



4.3.1 Web browsing using HTTP 



For the measurement of web browsing the reference server should contain a static version of the Copernicus reference 
webpage. 

The browser used for testing should behave similar to the browser used by most of the customers. It should be able to 
support the same HTTP capabilities and headers and open the same number of parallel download threads to download 
the content as the reference browser. 

After one test cycle (one download of the reference page), the complete data representation of the reference page 
content shall be cleared from the local cache of the browser. Furthermore, it should be made sure, that all TCP 
connections between the server and the client are closed (no HTTP keep alive). There should be a pause of at least 
6 seconds between the cycles. 

NOTE: Any data related to Performance Enhancement Proxy (PEP) settings, like JavaScript scripts or Cookies 
need to be prevented from getting cleared from the browser's cache. 

For the test, only HTTP download should be used. HTTP upload shall not be used. 

Testing of content integrity is not mandatory for this test, but highly recommended. 
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4.3.2 E-Mail access 

E-Mail Access should take place against a reference mail server. 

For the measurement of e-Mail services reference content should be used. 

A reference e-mail shall have a body containing only the string "Test" and attachment(s) chosen from the following 
reference content building blocks with respect to expected data rates of the network under test. 

Available building blocks are (files to be used as attachments): 100 kByte, 200 kByte, 500 kByte, 1MByte, 2 MByte, 
5 MByte, and 10 MByte. 

NOTE: See also the table in annex C for typical upload or download times versus file size and used data rate. 

These files contain random data to exclude optimizer/accelerator effects and are available on the ETSI server. 

A cycle should consist of mail upload using SMTP and mail download using IMAP or POP3. Both upload and 
download should represent typical user behaviour. 

After a test cycle, all TCP connections to the server should be disconnected. 

Testing of content integrity is mandatory for this test. 



4.3.3 File Transfer using FTP 

FTP testing should take place against a reference FTP server. The server should support the standard FTP commands 
and both active and passive mode transfer of data. There should be no bandwidth limitation on application level. 

In case of multisession scenarios, the reader shall be aware of the resulting effects with respect to the QoS parameters 
measured for each single session. With that, any use of multisession scenarios shall be stated in the results report. 

4.3.4 File Sharing using UDP 

To be decided. 

4.3.5 Synthetic tests 

4.3.5.1 UDP 

To be decided - Reference to iPerf. 

4.3.5.2 ICMP 

To be decided - Reference to TPING. 

4.3.5.3 TCP 

To be decided - Reference to TPING. 
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Annex A (informative); 
Reference SMS 



Content integrity of single SMs is ensured by mechanisms on lower protocol layers of GSM and UMTS networks. 
Thus, there is - from an E2E testing perspective - no need to implement content integrity checking mechanisms on top 
of the SMS service. Therefore, no reference SMS is provided by the present document 
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Annex B (informative): 
Content integrity checking 



Content integrity checking can be achieved by placing meta-information about the expected content in the retrieved 
documents and check if the content description matches the received content. If the description is put in the text payload 
of the content, it should survive compression and transcoding of the content during transportation from the server to the 
client. 



B.1 HTTP 



The text of the main reference page should contain the following description language in the main file of a test webpage 
(typically index.html). The text should substitute text present before in order to keep the length of the reference page 
constant. In order to avoid misinterpretation of the content description by common client software, established standards 
like XML or HTML should be avoided. 

The structure of the reference description is as follows: 

(% TAGNAME VALUE,[VALUE] %) 

Before each IE, an opening mark should be used, followed by a blank. The opening mark is a "(%" (Bracket-Open, 
followed by a Percent-Sign). The IE itself is identified by a tag called TAGNAME. Below is a list of all valid 
TAGNAMES. Each IE has one more parameters, called VALUES, separated by a comma. After the IE and its 
parameters a closing mark should be used. The closing mark is a "%)" (Percent-Sign, followed by a Bracket-Close). The 
opening and closing tags are separated from the TAGNAME and its parameters by a single blank space. The complete 
element should not be included within any HTML-format construct but should be place in pure text payload. 

TAGNAME PARAMETERS 

NAME <RESOURCENAME>, <APPROVED> 

This IE contains the name of the reference webpage. The first parameter <RESOURCENAME> describes the reference 
page. A full list of available pages is available in Appendix D.l. The second parameter <APPROVED> is set to for a 
resource not approved by ETSI and set to 1 for an ETSI approved resource. 

VERSION <VERSIONNUMBER> 

This IE contains a unique version number of this specific resource. 

TSIZE <TBYTES> 

This IE contains the accumulated size of all objects of the complete resource in bytes. 

OBJECTS <NUMBER> 

This IE contains the accumulated number of objects belonging to this specific page. 

OBJECT <OID>,<OFNAME>,<ONAME>,<OSIZE>, <OREQUIRED> 

For each object of the resource (identified by a separate file) a OBJECT tag should be available. Each OBJECT tag has 
5 mandatory parameters: 

• <OID> contains a unique identifier per object on this page, starting the count from 1 for the main 

index-file that includes the content description. 

• <OFNAME> contains the filename of the referenced object. 

• <ONAME> contains a description of the object. 

• <OSIZE> contains the original size of the object in bytes. 
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• <OREQUIRED> is set to 1 if the object relevant for customer perception. If the object may be removed while 
in transit the value should be set to (e.g. for advertisements). 

INFO <TEXT> 

This IE contains additional information about the resource. 



B.2 FTP 

Content integrity checking of a object transferred by FTP should be done by the use of MD5 checksums (16 bytes long). 
Two methods are supported: 

Method 1: 

In the same directory of the FTP server where the reference file is located lays a second file containing the MD5 
checksum of the reference file (identified by the same name, but a file name extension.MD5). By downloading both 
files, the test client can determine the content integrity of the reference file by calculating its MD5 checksum and 
comparing it to the value contained in the checksum file. 

To identify that method 1 is used the filename of the reference file starts with the fragment "CIC_M1_" followed by the 
name of the file plus extension. 

EXAMPLE 1: DEMO.TXT becomes CIC_Ml_DEMO.TXT and CIC_Ml_DEMO.MD5. 

Method 2: 

The MD5 checksum of the file is appended to the original reference file, increasing its size by 16 bytes. For content 
integrity check, the test client cuts the last 16 bytes of the downloaded file and calculates the MD5 checksum of the 
remaining fragment. This checksum can be compared to the checksum received with the last 16 bytes of the file. 

To identify that method 2 is used the filename of the reference file starts with the fragment "CIC_M2_" followed by the 
name of the file plus extension. 

EXAMPLE 2: DEMO.TXT becomes CIC M2 DEMO.TXT. 



B.3 MMS 

For further study. 
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Annex C (informative): 

Transfer times vs. used data rate and content size 

Table C.1 : Transfer times versus used data rate and content size 





Size 




100 kBytes 

(102 400 bytes) 


200 kBytes 

(204 800 bytes) 


500 
kBytes 

(512 000 
bytes) 


1 MBytes 

(1 048 576 
bytes) 


2 MBytes 

(2 097 1 52 
bytes) 


5 MBytes 

(5 242 880 
bytes) 


10 MBytes 

(10 485 760 
bytes) 


<D 

n 
n 

Q 


10 kbit/s 


81,92 s 


163,84 s 


409,6 s 


838,9 s 


1 677,7 s 


4 194,3 s 


8 388,6 s 


20 kbit/s 


40,96 s 


81,92 s 


204,8 s 


419,4 s 


838,9 s 


2 097,1 s 


4 194,3 s 


40 kbit/s 


20,48 s 


40,96 s 


102,4 s 


209,7 s 


419,4 s 


1 048,6 s 


2 097,2 s 


80 kbit/s 


10,24 s 


20,48 s 


51,2 s 


104,9 s 


209,7 s 


524,3 s 


1 048,6 s 


160 kbit/s 


5,12 s 


10,24 s 


25,6 s 


52,4 s 


104,9 s 


262,1 s 


524,3 s 


320 kbit/s 


2,56 s 


5,12 s 


12,8 s 


26,2 s 


52,4 s 


131,1 s 


262,1 s 


640 kbit/s 


1,28 s 


2,56 s 


6,4 s 


13,1 s 


26,2 s 


65,5 s 


131,1 s 


1 280 kbit/s 


0,64 s 


1,28 s 


3,2 s 


6,6 s 


13,1 s 


32,8 s 


65,5 s 


2 560 kbit/s 


0,32 s 


0,64 s 


1,6 s 


3,3 s 


6,6 s 


16,4 s 


32,8 s 


5 120 kbit/s 


0,16s 


0,32 s 


0,8 s 


1,6 s 


3,3 s 


8,2 s 


16,4 s 


10 240 kbit/s 


0,08 s 


0,16s 


0,4 s 


0,8 s 


1,6 s 


4,1 s 


8,2 s 


20 480 kbit/s 


0,04 s 


0,08 s 


0,2 s 


0,4 s 


0,8 s 


2,1 s 


4,1 s 
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Annex D (informative): 
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